Improve snowball stemming by adding an insert-only cache - #16356
Conversation
Avoid redundant Snowball stemmer invocations on repeated tokens via insert-only CharArrayMap cache; 2.3-2.7x faster. Default 1024 entries (~75 KB), disableable via constructor.
|
I don't think it's worth the extra complexity, to be honest. If you have costly components in your indexing pipeline then there's another idea you can try - wrap the costly pipeline into a top-level component which then returns all the cached attributes for a surface token image. The "cache" here can be dumb and just clear itself when it saturates (which is much simpler than any "real" hit-count cache) and just rely on token distribution. This works for everything (assuming context independance) and indeed can speed up processing... but it is something that users should/can configure themselves, knowing what their data and analysis pipeline is, I think. |
|
Also i wonder if the benchmark removed stopwords. They can really skew the results! If you don't want to remove stopwords, you can at least not pass them thru the stemmer, e.g. using KeywordMarkerFilter/StemmerOverrideFilter/ProtectedWordsFilter/etc. its the same idea: the very high frequency words go into a chararrayset and avoid being run thru the stemmer. |
|
Appreciate the feedback. Regarding the generic wrapping approach, I opted for improving the performance of the existing filters so that users can benefit from it after the upgrade without having to change their setup/mappings. I reran the benchmark with StopFilter in the pipeline (default English/German stop sets) to see the stopword removal impact: Stopword removal helps throughput (~50% for English and ~25% for German); the cache gives 2-3x on top of it.
(same hardware and JDK as before) |
I think this is the concern though. 75KB or N strings is too big by default. analyzer is cached in threadlocal and not just used at indexing time, but also at query time. For users with high query volumes, this cache would just cause problems I think. users have already complained before about the fact we reuse the termbuffer (termattribute), which is much less memory than this. Yes, the snowball stemmers are slower but most of our Analyzers don't default to them either... instead they default to lighter and faster approaches. For example, with English even if you dont want a light/minimal approach, you can use the PorterStemmer.java which is much faster than the snowball variant. That's the default used by EnglishAnalyzer. https://github.com/apache/lucene/blob/main/lucene/analysis/common/src/java/org/apache/lucene/analysis/en/EnglishAnalyzer.java#L108 For German, the default is also not snowball, but Savoy's: https://github.com/apache/lucene/blob/main/lucene/analysis/common/src/java/org/apache/lucene/analysis/de/GermanAnalyzer.java#L133 So I'm not sure who the users are that are using English/German snowball filters? If the user doesn't want to use stopfilter, again, if they can load the stoplist and protect it from being stemmed, they will see a perf improvement, but with much less memory usage and the set doesn't need to be duplicated everywhere but loaded a single time. Anyway, these are just my thoughts. For both these languages I think we have faster solutions already, and the faster solutions are already the default? |
Use languages where Snowball is the only stemmer available. Add numAnalyzers param to simulate multi-index memory pressure. Sweep cache sizes 64-512 to find the right default.
128 entries (~9KB) gives ~2x throughput while keeping memory bounded. Diminishing returns past 256 entries.
|
You're right, English and German were the wrong languages to benchmark. I reran the benchmark with the two languages and used different cache sizes for better tuning: (AMD EPYC, JDK 25, vocab=5000)
the sweet spot looks to be between 128-256. 128 entries take around ~9KB (capped) for ~2x better stemming so made that the default.
Agreed this works and it's a good complementary technique. |
|
but its just filling tokens until its full right? So if your first document has a distribution than all the others then it will just perform badly? Wouldn't it be more effective if cache used LRU-type behavior so that it retained the most frequent inputs? AFAIK the CharArrayMap doesn't support such semantics (e.g. removeEldestEntry) or anything. Maybe I am missing something. |
Cache is allocated lazily on first cacheable token. When full, clears and refills from subsequent tokens to adapt to distribution changes since CharArrayMap does not support removal/LRU. Updated benchmark to process corpus as multiple documents matching real indexing.
|
Good point. Updated benchmark results:
|
I don't understand this, usually analyzers stem at query-time too. |
|
Sorry, you're right. I was thinking of analyzers that haven't processed any tokens yet (such as unused indices). |
Snowball stemming is expensive due to algorithmic suffix manipulation repeated identically for every occurrence of the same token.
This PR adds an small insert-only cache (CharArrayMap) to avoid the redundant work by exploiting the fact that natural text is Zipfian (same short words account for majority of token occurrences).
The cache is small (1024 entries, ~75KB) and caches only tokens up to 10 chars.
It is enabled by default to avoid mapping changes for existing users and can be disabled through maxCacheSize=0.
Benchmarks
AMD EPYC 7R32 (c5a.2xlarge), JDK 25, 500 unique words, 10K tokens Zipfian corpus. 3 forks, 10 iters × 1s. cacheSize=0 is the uncached baseline.
The default cache size of 1024 entries was picked from the sweep above as it captures virtually all the benefits across English and German.